feat(chroma/make): new makefile colorization caching strategy #82
Conversation
* fix(make): colorize targets from imported make-files Old behavior use to parse the content of the invoked `Makefile` unit to define targets. Such parsing didn't take into account targets from unit imported by the current (ex: targets defined in files imported such as `import ./targets/help.mk`). New behavior pass the content of the Makefile unit post lexing (aka `make -f Makefile -pn` instead of the plain unit. * Update →chroma/-make.ch --------- Co-authored-by: Philipp Schmitt <[email protected]>
|
There should be a regression to the old behavior until there is a solution that causes no delay, because this will cause a delay on each key presses on larger makefile units. |
|
@HearseDev I'll introduce my enhancements with this MR (shared caching, one caching item per path). Probably @pschmitt or some other maintainer could revert in another dedicated MR #81 until then |
|
I saw this one too, hope it will be merged fast edit: deffinitly better with this PR, but far from perfect after you type |
Working locally on some version where units are re-parsed only when the content has changed. Should be published by the end of the day |
|
I added |
burgesQ
force-pushed
the
master-make-3
branch
3 times, most recently
from
3dec7e6 to
628754c
Compare
One may enable the shared cache by setting the following prior to loading the fast-synthax-highlighting module ```sh typeset -gA FAST_HIGHLIGHT FAST_HIGHLIGHT[chroma-make-cache-global]=1 ``` This new implementation change the way the cached makefile' parsed content are expired. Prior to this commit, cached item expired after 7s. The new implementation get ride of the timer limit and replace it with a good old "is my file content's different"
|
works as expected here |
burgesQ
changed the title
|
@pschmitt can this not be the default, because this literally makes the shell unusable on large makefile units. |
|
@burgesQ @phush0 @pschmitt how do I disable this in upstream or go back to the original behavior without modifying the repo, because it literally freezes my terminal. How is this in the main branch with huge delays/freezes, are there no tests performed with large makefile units, or makefile build systems before it's merged. I have tried both: and |
|
both global and 7sec delay strategies cause the terminal to freeze on large makefile units/build systems with multiple makefiles, it would be the logical thing to regress these changes and go back to old behavior until this can be reproduced/tested and fixed. |
|
This is what I tried to achive but no one took it, design is broken because make is called always nomatter the cache |
|
#83 skip the call to make if cache sharing isn't enabled - should fix ur cases sirs @phush0 @HearseDev Btw if one could share a buggy Makefile so I could run tests against it. |
https://github.com/theos/theos and use nic.pl to generate any project, and just type make |
4 participants
Description
Update the way cached makefile metadata are cached.\
Up until now, a single cache item (7s TTL) was generated whatever makefile was used.\
This new implementation allows generating a cache item per makefile path + content pair; allowing to get rid of the TTL.
One may enable the new strategy by setting the following prior to source fast-synthax-highlighting
typeset -gA FAST_HIGHLIGHT FAST_HIGHLIGHT[chroma-make-cache-global]=1Related Issue(s)
Some comments following https://github.com/zdharma-continuum/fast-syntax-highlighting/pull/81/files (dcee72b#commitcomment-161064002 & other)
Motivation and Context
Parsing Makefile targets is now expensive because of me, so let's attempt to run it as less as we needs
Usage examples
How Has This Been Tested?
Locally 🤓
Types of changes
Checklist: